(12) DEMANDE INTERNATIONALE PUBLIEE EN VERTU DU TRA1TE DE COOPERATION 

EN M ATI ERE DE BREVETS (PCT) 



(19) Organisation Mondiale de la Propriete 
lntellectuelle 

Bureau international 




143)Date-de-»a-publicat»oninternat«onale (10) Numero de publication-iiiternationale- 
14 juin 2001 (14.06.2001) PCT WO 01/42887 A2 



(51) Classification Internationale des brevets 7 : G06F 1/00 

(21) Numero de la demande Internationale: 

— PCT/FR00/03463 

(22) Date de depot international: 

8 decembre 2000 (08. 1 2.2000) 

(25) Langue de depot: francos 

(26) Langue de publication: frangais 

(30) Donnees relatives a la priorite: 

99/15791 lOde-cembre 1999(10.12.1999) FR 

(71) Deposant (pour tous les Etats designes sauf US): GEM- 
PLUS [FR/FR]; Avenue du Pic de Bertagne, Pare d'Activ- 
ites de Gemenos, F- 13420 Gemenos (FR). 



(72) Inventeurs; et 

(75) Inventeurs/Deposants(/x?ur US seulement): GRIMAUD, 
Gilles [FR/FRJ; 7, rue Saime Anne, F-59800 Lille (FR). 

HAG1MONT, Daniel IFR/FR];J73 rue du 1? Mars 1962, 

F-38920 Crolles (FR). VANDEWALLE, Jean-Jacques 
[FR/FR]; 18, rue Bernardy, F- 13001 Marseille (FR). 

(81) Etats designes (national): AE, AG, AL, AM, AT, AU, AZ, 
BA, BB. BG, BR, BY, BZ, CA, CH, CN, CR, CU, CZ, DE, 
DK, DM, DZ, EE, ES, Fl, GB. GD, GE, GH, GM, HR, HU, 
ID, IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, LK, LR, LS, 
LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, NO, 
NZ, PL, FT, RO, RU, SD, SE, SG, SI, SK, SL, TLTM,TR, 
TT, TZ, UA, UG, US, UZ, VN, YU, ZA, ZW. 

(84) Etats designes (regional): brevet ARIPO (GH, GM, KE, 
LS, MW, MZ, SD, SL, SZ, TZ, UG, ZW), brevet eurasien 
(AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), brevet europeen 
(AT, BE, CH, CY, DE, DK, ES, Fl, FR, GB, GR, IE, IT, LU, 

[Suite sur la page suivante] 



= (54) Title: CAPABILITY-BASED ACCESS CONTROL FOR APPLICATIONS IN PARTICULAR CO-OPERATING APPL1CA- 
j| TIONS IN A CHIP CARD 

|H (54) Titre: CONTROLE D'ACCES PAR CAPACITES POUR DES APPLICATIONS NOTAMMENT COOPERANTES DANS 
= UNE CARTE A PUCE 



DARTING STATION 

SA 



< 
oo 

00 




o 



(57) Abstract: The invention concerns an application programmer no longer responsible for managing access rights, the application 
code being independent of the protection in the chip card. The capability-based access control consists, when an application (Aa), 
for example in a docking station, is given access to an object (Obl) pertaining to the other application (Ab) in a chip card (CP), in 
creating two capabilities (Fa(Obl), Fb(Obl)) respectively in the applications, as objects, to protect all subsequent accesses to the 
object by filtering them through the two capabilities. On accessing (El ) an object (Obl ) pertaining to an application ( Ab), if a second 
object (Ob2) pertaining to the other application (Ab) is passed on to the latter, two other capabiliiies (Fa(ObZ Fb(Ob2)) are added 
(E2) in the applications to protect access to the second object. 
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Sans rapport de recherche Internationale, sera republiee 

des^ec^iorTdece rapport. ~~ 



En ce qui concerne les codes a deux lettres et autres abrevia- 
tions. se referer aux "Notes expUcatives relatives aux codes et 
abreviations" figurant au debut de chaque numero ordinaire de 
la Gazette du PCT. 



(57) Abrej>e- Un programmer ^applications ne se soucie plus de la gestion des droits d' acces, le code des applications elant 
mdependant de la protection dans one carte a puce. Le contole d'acces par capacites comprend, lorsqu'a une application (Aa). par 
exemple dans une station d'accueil de carte, est dorm* un acces a un objet (Obi ) appartenant a 1' autre application (Ab) dans une carte 
a mice (CP) la creation de deux capacites (Fa(Obl), Fb(Obl)) respectivement dans les applications, en tant qu'objets, pour proper 
tous les acces ulterieurs a l'objet en les filtrant au travers des deux capacites. Lors de I'acces (El) a un objet (Obi) appartenant a 
une application (Ab), si un deuxieme objet (Ob2) appartenant a Vautre application (Ab) est passe" a cclle-ci, deux autres capacites 
(Fa(Ob2), Fb(Ob2)) sont ajoutees (E2) dans les applications pour protcger Faeces au deuxieme objet. 
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Controle d'acces par capacites pour des applications 
notamment cooperantes dans vine carte a puce 

L 1 invention concerne les cartes a puce, ~dites 
egalement cartes a microcontroleur ou cartes a 
circuit integre, et plus generalement des moyens de 
traitement de donnees ouverts programmables pouvant 
etre charges ' d ' applications ecrites dans des langage 
de programmation evolues. 

Une carte a puce ouverte, telle que presentee 
par exemple dans le document WO 98/19237, gere 
plusieurs applications, par exemple un compte client 
pour un magasin, un compte bancaire ou un porte- 
monnaie electronique . Certaines applications chargees 
dans la carte cooperent parfois par exemple pour 
payer un achat du magasin, et/ou cooperent egalement 
avec des applications s 1 executant hors de la carte. 

La cooperation des applications impose 
1 » etablissement de regies de droit d'acces, les 
applications ne se faisant pas forcement confiance. 
Par exemple, le compte client gere par le magasin ne 
doit pas s'approprier de donnees gerees par le porte- 
monnaie electronique. 

Dans un environnement* inf ormatique, la gestion 
du controle d'acces consiste a associer des droits 
d'acces a des objets geres dans 1 1 environnement pour 
chaque usager, et a verifier que ces droits d'acces 
sont respectes. 

La gestion du controle d'acces est schematisee a 
la figure 1 par la gestion d'une matrice d'acces MA. 
Les lignes de la matrice MA correspondent aux droits 
de J objets Ol a OJ et les colonnes de cette matrice 
correspondent aux droits de I usagers Ul a UI . Une 
case de la matrice a 1 • intersection d'une ligne et 
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d'une colonne donne des droits d'acces Dij d'un 
usager Ui sur un objet 0 j , avec 1 = i = I et 1 = j = 

j_ par _ exemple -un — droit — de- -lire., — d- , ecrire_„ou_ 

d'executer un fichier. 

5 En pratique, la matrice MA est partiellement 

vide, des usagers n'ayant souvent aucun droit sur de 

-nombreux -objets-* - -et- -presente -1-Uzne des _ deux „ 

configurations consistant en un regroupement des 
droits d'acces par ligne et en un regroupement des 

io droits d'acces par colonne. 

Le regroupement par ligne revient a associer a 
chaque objet O j , une liste d'acces indiquant les 
droits d'acces Dlj a Dij sur 1 'objet respectivement 
pour les usagers Ul a UI. Dans une gestion par listes 

15 d'acces respectivement associees a des objets, seul 
le proprietaire d'un objet Oj modifie la liste 
d'acces Dlj a Dij associee a 1' objet ; une telle 
modification se fait explicitement en . appelant une 
operation sur 1 'objet demandant la modification de sa 

20 liste d'acces. Les schemas de protection a base de 
listes d'acces sont alors qualifies de statiques, la 
modification des droits d'acces etant complexe et les 
usagers ayant tendance a surdimensionner les droits 
d'acces de leurs objets. Ceci va a l'encontre du 

25 principe du moindre privilege (en anglais : need to 
know principle) selon lequel des droits d'acces ne 
sont accordes qu'au fur et a mesure des besoins. 

Le regroupement par colonne associe a chaque 
usager Ui une liste de capacites indiquant les droits 

30 d'acces Dil a DiJ de 1 'usager respectivement pour les 
objets sur lesquels 1 'usager possede un droit. Chaque 
element (Oj, Dij) de la liste est appele une 
capacite. Une capacite est un descripteur contenant 
1 'identification d'un objet Oj ainsi qu'une 

35 definition de droits d'acces Dij sur cet objet. Dans 
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une gestion par capacites, un usager possede une 
liste de capacites, une capacite pouvant etre 
comparee a un jeton dormant le droit de f aire" une" 
operation sur I'objet. Une capacite identifie un 
5 objet, mais inclut en plus une definition des droits 
d'acces sur I'objet. Une capacite peut alors etre 
utilisee comme un identif icateur d' objet ~ qu'uhe' 
application peut passer en parametre a une autre 
application, en suivant un mode de progr animation 
10 classique, avec la limitation que cet identif icateur 
n'autorise pas toutes les operations sur I'objet 
designe. 

II en decoule que la modification des droits 
d'acces est plus naturelle avec des capacites : 

is accorder a une application ou un usager des droits 
d'acces a un objet revient a lui passer en parametre 
d'une operation l'identite de I'objet sous la forme 
d'une capacite. 

Les capacites apportent une plus grande 

20 dynamique dans la gestion du controle d'acces, les 
droits d'acces pouvant etre aisement echanges entre 
les usagers de 1 ' environnement . Cependant , lorsqu 1 un 
usager ou une application doit passer en parametre 
une capacite sur un objet, 1' usager ou 1 1 application 

25 doit auparavant decider des droits a transferer avec 
la capacite. Une operation permet en general de 
reduire les droits associes a la capacity si 
necessaire, avant de la passer en parametre. 

Dans la technique anterieure, sont connues des 

30 realisations materielles et des realisations 
logicielles des capacites comparables a des jetons. 
Les premieres realisations materielles reposaient sur 
des machines specialisees dans les annees 70. Le 
mecanisme d'adressage de ces machines implantait 

35 directement la notion de capacite : un registre 
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d'adresse servant a adresser un obje.t contenait 
egalement les droits d'acces a l'objet (le registre 
contenant le jetonH Les valeurs de ces regTstfres 
pouvaient etre echangees entre les usagers, mais ne 
5 pouvaient pas gtre forgees, le materiel ne le 
permettant pas. Les realisations logicielles, plus 
recent es dans~ les ahriees" " 80 ~, ~ reposaientT " siir" le — 
chiffrement pour la protection des capacites. Une 
capacite etait signee et ne pouvait etre creee que 

10 par le propri^taire de l'objet. 

Ainsi, le document US 5781633 illustre une 
technique anterieure permettant un filtrage, au moyen 
de capacites, d'echanges de references d'objets entre 
differents processus. Des procedes cryptographiques 

15 sont utilises pour garantir principalement 
l'integrite des references echangees. La cooperation 
entre processus est realisee par la transmission 
d'une vue reduite d'un objet d'un processus, a un 
second processus. Le filtre ainsi cree est implante 

20 au sein du processus demandeur d'acces. Dans un 
contexte de type « processus mutuellement mefiants », 
le procede divulgue par le document est inoperant. En 
effet le processus demandeur d'acces peut modifier a 
sa guise le filtre qui lui a ete transmis et acceder 
25 ainsi a des m£thodes qui lui sont pourtant 
interdites . 

L 1 invention a trait plus particulierement a un 
mecanisme de controle d'acces base sur un schema de 

30 protection par capacites pour gerer la cooperation 
entre des applications dans le contexte d'une carte a 
puce. En effet, le contexte de la carte a puce se 
caracterise par des cooperations entre des 
applications non prevues a I'avance. II est done 

35 difficile de satisfaire un schema de protection comme 
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les listes d'acces du les droits d'acces sont le plus 
souvent pre-etablis. La dynamique du schema a base de 



capacites est un reel besoin. 



10 



Dans les solutions actuelles dans le contexte de 
la carte a puce, un programmeur doit gerer des 
capacites ''a la main 11 dans le code de 1 ' application, 
" C e ~qui~ conduit a une" complexite de-programmation-des- 
applications protegees. 

L 1 invention implante un modele a capacite dans 
le contexte de la carte a puce pour poursuivre deux 
objectifs : 

- Preserver la simplicite de programmation du 
langage JAVA dans le contexte de la JAVA Card. Pour 
ce faire, 1' invention vise a rendre le code des 

15 applications independant de la protection. La 
specification de la politique de protection, c'est-a- 
dire de la gestion des capacites, est separee du code 
des applications. 

Permettre la cooperation entre des 

20 applications dans la carte, mais egalement entre des 
applications dans la carte et des applications hors 
de la carte. Ceci necessite de considerer le systeme 
d ' exploitation dans la carte comme un milieu securise 
et 1'exterieur de la carte comme un milieu hostile. 

25 L'atteinte de ces deux objectifs par 1' invention 

apporte une grande simplicite de programmation du 
controle d^cces, ce qui reduit egalement le cout de 
developpement et de maintenance du code, ainsi que 
les risques d'erreur de programmation de la 

30 protection. 

Le premier objectif conduit a separer le 
developpement de 1 1 application et la gestion des 
droits d f acces, simplifiant ainsi la complexite. Le 
programmeur d ' applications programme des applications 

35 sans se soucier de la gestion des droits d'acces. 
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Celle-ci est specifiee separement dans un formal isme 
simple et tres intuitif . 

Pour— le— deuxi erne— object if- — l-'invention - of f re~ufi 

modele de gestion des droits d'acces uniforme alors 
5 que les contraintes sous- jacentes sont tres 
differentes lorsque l'on se trouve dans la carte ou 

— _ hor s de la carte— — ^ 

Les deux object if s repondent a la meme 
motivation consistant a masquer les complexites 
10 inherentes a la protection et a la carte, et a 
simplifier la programmation d ' applications 
cooperantes protegees. 

Pour atteindre ces objectifs, 1' invention fournit 
15 un procede de generation d' applications caracterise 
en ce qu'il comprend : 

- une etape de developper une application 
comprenant un objet ou plusieurs objets, sans 
restriction d'acces ; 

20 - une etape de definir des regies de droits 

d'acces a 1' objet ou aux objets, compris au sein de 
1' application, depuis une seconde application ou 
depuis plusieurs autres applications ; 

- une etape de transformer 1 ' application 
25 comprenant le ou les objets par ajout a ladite 

application, de moyens de filtrage des acces audit 
objet ou auxdits objets pour mettre en ceuvre un 
procede de controle d'acces assurant la cooperation 
des applications; 
30 - une etape d'implanter 1 ' application 

transformee au sein d'un moyen de traitement de 
donnees . 

Selon une premiere realisation, le moyen de 
traitement de donnees est inclus dans une carte a 
35 puce. 
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Selon une seconde realisation, le tnoyen de 
traitement de donnees est inclus dans une station 

, d^accue il de la ca rte a .puce.. 

En outre, selon 1' invention, le precede de controle 
5 d'acces entre deux applications cooperant chacune au moyen 
de capacites sur des objets appartenant a 1' autre 
application, les applications cooperant a travers au moins 
~~un~ systdme" d 1 exploitation, est caractgrise par l'§tape 
suivante : 

10 lorsqu'a l'une des applications, dite 

application demandeur d'acces, est donne un acces a 
un objet appartenant a 1' autre application, dite 
application fournisseur d'acces ; 

creer deux capacites respect ivement dans 
is lesdites applications demandeur et fournisseur 
d'acces, en tant qu' objets ; 

la capacite creee dans 1 ' application fournisseur 
d'acces pour limiter 1 ' acces audit objet et ; 

la capacite creee dans 1 ' application demandeur 
20 d'acces pour associer 1 ' application demandeur d'acces 
a la capacite creee dans 1' application fournisseur 
d'acces. 

Selon un autre aspect de 1' invention, lors de 
1' acces a un objet appartenant a l'une des 

25 applications, si un deuxieme objet appartenant a 
l'une des applications est passe a cette application, 
le procede comprend l'etape d'ajouter deux autres 
capacites respect ivement dans les applications pour 
proteger 1' acces au deuxieme objet. 

30 En pratique, la capacite d'acces au deuxieme 

objet appartenant a l'une des applications est pass£e 
en parametre ou en resultat a l'autre application. 

Selon une premiere realisation, les applications 
peuvent etre implantees dans un moyen traitement de 

35 donnees commun, par exemple dans une carte a puce ou 
un terminal. Dans le cas d'une carte a puce, les 
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verifications du code charge dans la carte a puce 
permettent d 1 assurer qu'une capacite ne peut etre 
~cr6"ee - par-un-prograrraneur-pirate. 



Selon une deuxieme realisation, les applications 
5 sont implantees dans deux moyens de traitement de 
donnees distants echangeant des messages d'acces a 

des "objets" distant s . -L-' et ape" d'ajouter deux^autres - 

capacites peut comprendre alors de preference le 
stockage d'un mot secret dans les deux autres 
io capacites, passe a celles-ci par les deux capacites 
precedemment creees a I'etape de creer, afin de 
valider l'acces au deuxieme objet. 

Les moyens de traitement de donnees peuvent etre 
inclus respect ivement dans une carte a puce et une 
15 station d'accueil de la carte a puce, ou dans deux 
cartes a puce distinctes, ou dans deux controleurs 
d'une carte a puce ou d'un terminal. 

D' autres caracteristiques et avantages de la 
20 prdsente invention apparaitront plus clairement a la 
lecture de la description suivante de plusieurs 
realisations preferees de 1' invention en reference 
aux dessins annexes correspondants dans lesquels : 

- la figure 1 montre une matrice de droits 
25 d'acces deja commentee ; 

- la figure 2 est un bloc-diagramme montrant des 
interfaces entre une application banque et une 
application client ; 

- la figure 3 est un bloc-diagramme montrant des 
30 interfaces de. deux applications cooperantes selon 

1' invent ion ; 

- la figure 4 est un bloc-diagramme montrant 
1 ' implantation d'objets filtres entre deux 
applications cooperantes a une etape initiale de 

35 procede selon 1' invention ; 
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- la figure 5 est un bloc-diagramme . montrant 
l'adjonction de deux filtres lors de l'appel par une 

application— de— la-met hode— sur-un -premier- objet -dans 

Une autre application, selon une premiere realisation 
5 du procede* de 1 ' invention ; et 

- la figure 6 est un bloc-diagramme analogue a 

la- f igure 5v -montrant 1-' adjonction ~de deux -f iitres - 

lors de l'appel par une application dans une station 
d'appel de la methode sur un premier objet dans une 
io autre application dans une carte a puce, selon une 
deuxieme realisation de 1' invention. 

Le concept general sous-jacent a 1' invention est 
la gestion de capacites, c'est-a-dire la gestion de 
15 droits d'acces elementaires, ^de fagon separee d'une 
application. 

Lorsque deux applications cooperent, cette 
cooperation suit un protocole de cooperation pre- 
6tabli. Ce protocole de cooperation prend 

20 generalement la forme d'une interface commune 
permettant aux applications de s'appeler. Plus 
precisement, dans le contexte de la JAVA Card, chaque 
application qui desire appeler une autre application 
le fait en utilisant une interface JAVA qui est celle 

25 qu'est sensee fournir 1 'application appelee. 

En reference a l'exemple illustre a la figure 2, 
une banque BA, c'est-a-dire une application banque 
dans un serveur, gere des comptes pour des clients. 
Lorsqu'un client CL se connecte a la banque a travers 

30 un objet Guichet OG, la banque lui retourne une 
reference Ref sur son objet Compte en banque OC pour 
qu'il puisse lire I'etat de son compte. Chacune des 
applications banque et client connait les interfaces 
de cooperation IG et IC qui sont celles des objets 

35 Guichet et Compte- L* interface de 1' objet Guichet IG 
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permet au client de se connecter a la banque en 
donnant son nom et un code d'acces, tel qu'un code 

dT'TaentreS-- personnel— pin- (Personal- Identity— Number.)., 

et de lui retourner la reference Ref a 1' objet Compte 
5 OC. L ! interface de 1' objet Compte IC fournit deux 
methodes respect ivement pour lire et ecrire le solde 
" ~ du compte " en"banque ~ la - syntaxe -uti-lisee -etant .celle. 
du langage JAVA. 

Les besoins en termes de. protection dans cet 
io exemple sont presentes ci-apres. La banque possede 
tous les droits sur ses propres objets. Mais il est 
impensable que la banque accorde tous les droits a 
ses clients. Un client peut lire le solde de son 
compte en banque, mais ne doit pas etre autorise a 
15 ecrire arbitrairement le solde de son compte. C'est 
pourquoi, dans un schema de protection par capacites, 
la banque retourne en resultat de l 1 operation de 
connexion une capacite correspondant a la reference 
sur l'objet Compte, mais avec des droits qui ne 
20 permettent que 1'appel de 1 ' operation de lecture de 
compte. La banque qui possede tous les droits sur ses 
propres objets, y compris l'objet Compte, cree une 
capacite n'autorisant que la lecture sur cet objet et 
retourne cette capacite a son client. 
25 Etant donne que le premier objectif vise par 

1» invention est de separer la definition de la 
politique de protection et le code de 1 1 application, 
1» invention vise plus particulierement a fournir des 
regies d^change de capacite entre les applications 
30 au niveau des interfaces utilisees pour cooperer. 

Dans 1' exemple montre a la figure 2, la 
fourniture du controle d'acces par programmation est 
situee au niveau de 1' interface de 1' objet Guichet OG 
de la banque BA . Selon un premier aspect • de 
35 1' invention, cet outil de programmation specif ie dans 
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les interfaces utilisees la capacite qu'il faut 
transferer lors d'une transmission de parametre entre 
^es~a^rications— On-obtient-une— inter-face— ^protegee" 
appelee vue {view en anglais) qui prend la forme 
suivante en langage JAVA, le mot "String" designant 
un objet de chaine de caracteres : 



view guichet { 

Carptejolient connexion (String nam, String pin-code) ;. 

10 j 

view Comptejclient { 

Solde lire () ; 

NOT void ecrire (Solde s) ; 

} 



La specification de ces deux vues indique que la 
banque BA ne laisse sortir que des capacites 
permettant de lire le solde des comptes. Le code .de 
1 » application banque et de 1 1 application client reste 
20 ainsi totalement independant de la protection. 

De fagon plus generale, I'outil de programmation 
permet a chacune des applications, 1 1 application 
banque et 1 1 application client selon 1 1 exemple 
precedent, de definir ses propres regies de 
protection. Lorsqu f une application AA possede une 
capacite vers un objet OB d'une application AB comme 
montre a la figure 3, la capacite inclut les regies 
de protection definies par 1 1 application AA et 
regroupees dans une interface protegee "vue" IA et 
les regies de protection definies par 1 ' application 
AB et regroupees dans une interface protegee "vue" 
IB. La vue IB a deux roles : limiter les methodes que 
1 -application AA peut appeler sur I'objet OB et 
associer la vue choisie par 1 • application AB aux 
capacites entrantes dans et sortantes de 



35 
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1 1 application AB lorsque l f objet OB est appele. La 
vue IA ne remplit que le deuxieme role pour les 

capacites entrantes dans et sort-antes de 

1 1 application AA. 
5 Ainsi, pour chaque capacite echang6e en 

parametre de l'appel depuis 1' application AA vers 
i « a ppli"cation--AB- / ~ou- depuis- 1-' application- AB- -vers 
1 ' application AA, la vue IA associe une vue IA 1 a 
cette capacite et la vue IB associe une vue IB 1 a 
10 cette capacite. 

Un autre aspect de 1" invention est 1 1 integration 
de l'outil de prog rammat ion dans le contexte de la 
carte a puce. Dans le contexte d' une carte a puce 
is ouverte, des applications sont chargees dans la 
carte. Ces applications, dites applications internes, 
interagissent entre elles, mais egalement avec des 
applications, dites applications externes, executees 
dans une station d'accueil, telle qu'un terminal 
20 bancaire, un point de vente ou un terminal 
radiotelephonique mobile, dans laquelle la carte est 
inseree. Ceci implique que des capacites sont 
echangees entre des applications internes et des 
application externes. L'outil de programmation 
25 associe a 1" invention est mis en place en considerant 
les parties suivantes de ce contexte liees a la carte 
et a la station d ! accueil : 

- La carte a puce JAVA Card est un milieu 
protege dans le sens ou le code JAVA charge dans la 
30 carte a puce est verifie avant son chargement 
effectif. Cette verification vise a assurer que le 
code a charger possede bien certaines propri£tes du 
code JAVA, principalement liees a la securite. Le 
langage JAVA ne permet pas de manipuler directement 
35 des adresses et done d'ecraser arbi trairement de la 
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memoire, ce qui assure un certain degre de securite 
lorsque differents progranunes sont heberges dans la 

meme machine vir tuelle JAVA LAimplantation- du-schema 

de protection de 1' invention tient compte de ce 
5 contexte interne a la carte pour 1 1 implantation des 
capacites dans la carte. 

r^_ L 5* „sjtation__dVaccueil- dans_ laquel-le — la- earte- 

est inseree n'est pas forcement un milieu securise. 
En effet, la carte peut etre inseree dans n'importe 
10 quelle station d'accueil, et la station d'accueil 
peut tres bien envoyer des donnees fabriquees pour 
tromper la carte. Lorsqu 1 elles sont propagees hors de 
la carte, les capacites sont selon 1" invention 
protegees par des secrets qui permettent de verifier 
15 la validite des capacites utilisees par des 
applications ext ernes a la carte. 

L' invention porte ainsi sur un outil de 
programmation pour programmer la gestion des droits 
d'acces entre des applications cooperantes 
20 s' executant dans la carte a puce ou dans la station 
d'accueil. La definition des regies de gestion des 
droits d'acces est separee du code des applications, 
ce qui confere une plus grande clarte. L» integration 
dans le contexte de la carte a puce JAVA Card 
25 necessite de gerer differemment les capacites dans la 
carte a puce et a I'exterieur de celle-ci. 

L 1 outil de programmation associg a 1* invent ion 
specif ie les regies de protection d'une application 
30 separement du code de 1 1 application . 

II est suppose qu'une premiere application Aa 
ecrite en langage JAVA coopere avec une deuxieme 
application Ab egalement ecrite en langage JAVA a 
travers une interface de cooperation lab implantee 
35 dans un unique moyen de traitement de donnees, par 
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exemple une carte a puce avec un systeme 
d» exploitation specif ique et la machine virtuelle 
" JAVA" : 

interface lab { 

void methl (II pi) ; 

I2 - me th2 () ;- " 

void meth3 () ; 

} 

L' interface lab contient les definitions de 
trois methodes methl, meth2 et meth3 . La methode 
methl prend en parametre pi une reference a un objet 
de type interface II et ne retourne aucun resultat. 
La methode meth2 ne prend aucun parametre et retourne 
un resultat de type interface 12. La methode meth3 ne 
prend aucun parametre et ne retourne aucun resultat . 

Chaque application specifie alors des interfaces 
de protection appelees vues, par exemple les vues 
suivantes Iab_V, I1_V1 et I2_V2 : 

view Iab_v{ 

void methl (I1_V1 pi) ; 
12JJ2 meth2 () ; 
NOT void meth3 () ; 

} 

Lorsque 1 1 application Aa possede une capacity 
sur un objet appartenant a 1 ' application Ab, les 
applications Aa et Ab ont la possibility de specifier 
la protection a associer a cette capacite en 
associant une vue a cette capacite. 

La vue Iab_V indique que seules les methodes 
methl et meth2 sont autorisees. Elle indique aussi 
que si la methode methl est appelee, alors 
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1 'application, qui peut etre une application 

appelant e ou une application appelee, se protege en 
associant -a—; l-a~eapaei-t-e~passee— en~ paramStre - la - vue 

I1_V1. Enfin, elle indique que si la methode meth2 
5 est appelee, alors 1 •application se protege en 

associant a la capacite passee en resultat la vue 
I2-V2 

Lorsque 1 Application Aa possede une capacite 
vers un objet de 1 ' application Ab, la vue que 
10 1 'application Aa associe a cette capacite permet a 
1 -application Aa de controler les capacity qui 
entrent dans et sortent de celle-ci, c'est-a-dire 
d'associer a ces capacites une vue. Reciproquement , 
la vue que 1 1 application Ab associe a cette capacite 
15 permet a 1 'application Ab de controler les capacites 
qui entrent dans et sortent de celle-ci, mais aussi 
de limiter les methodes qui peuvent etre appel£es sur 
1' objet de 1 ■ application Ab. 

En general, la premiere exportation d'une 
20 capacite d'acces depuis 1 1 application Ab vers 1" autre 
application Aa et la premiere importation de cette 
capacite par 1 'autre application Aa, passent par un 
serveur de nom. L ' application Ab exporte la capacite 
d'acces en 1 'associant a un nom symbolique, tel 
25 qu'une chaine de caracteres, et 1 'application Aa 
importe la capacite" d'acces export ee en interrogeant 
le serveur de nom avec le nom symbolique. 
L' application Ab exporte la capacite en specif iant 
explicitement la vue que 1 ' application Ab y associe. 
30 L' application Aa importe la capacite exportee en 
specif iant explicitement la vue que 1 ' application Aa 
y associe. Pour 1 ' application Aa comme pour 
1 'application Ab, la vue specif iee indique pour tous 
les echanges de capacite en parametre decoulant de ce 
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premier echange, les vues qui seront associees a ces 
capacites passees en parametre. 

II en resulte q ue, exce pte ce p remier ech ange de 

message de capacite d» acces, la politique de 
5 protection de chaque application selon 1* invention, 
c'est-a-dire la maniere d'echanger les capacites, est 
_ specif iee_ aij niveau des interfaces^ et n ! est^ pas_nqyee 
dans le code de 1 1 application . 

10 L 1 implantation de la politique de protection 

selon 1' invent ion repose sur la notion d'objets 
filtres, "illustrant" des objets capacites 
(signifiant aptitudes ou facultes, ou en anglais 
"capabilities"), qui sont inseres entre les 

15 applications Aa et Ab. Pour chaque vue definie par 
une application, une classe filtre est generee et une 
instance de cette classe est inseree a 1' execution 
dans la chaine d' acces a un objet dont une capacite 
est exportee. Comme montre a la figure 4, si a une 

20 etape initiale E0 un acces a un objet Ob appartenant 
a 1 'application Ab est donne a 1 1 application Aa, la 
vue de 1 1 application Aa pour la capacite de cet acces 
est implantee par un filtre Fa et la vue de 
1 'application Ab pour cette capacite est implantee 

25 par un filtre Fb. 

Une classe filtre definit toutes les methodes 
declarees dans la vue que le filtre implante. Son 
role est de retransmettre l'appel de methode vers son 
successeur dans la chaine d'acces a l'objet. Selon 

30 l'exemple montre a la figure 4, le filtre Fa 
retransmet l'appel vers le filtre Fb et le filtre Fb 
vers 1* objet Ob. 

Par contre, une classe filtre implante la 
politique de protection definie par la vue a partir 

35 de laquelle elle est generee : le filtre Fb ne laisse 
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passer que les methodes autorisees par la vue de 
1 'application Ab ; et les filtres Fa et Fb implantent 

— aussi— 1— association-des—vues— aux-capae-i-fces— passees- en 

parametre. Selon l'exemple de vues ci-dessus, la vue 
5 Iab_V indique 1 1 association de la vue I1_V1 au 
parametre pi de la methode methl . L ' association de la 

— vue - a -la capacite— est -imp! ant ee -en— inserant- dans -la— 

chaine d'acces a 1 'objet passe en parametre un objet 
filtre correspondant a la vue. 
10 En reference a la figure 5, pour deux 

applications Aa et Ab implantees dans une carte a 
puce CP, 1 'application Aa possede a l f etape initiale 
E0 une capacite vers l'objet Ob de 1 1 application Ab, 
et comme dans la figure 4, les acces ulterieurs a 
15 l'objet Ob sont proteges par le filtre Fa (Ob) de 
1 'application Aa et par le filtre Fb(Ob) de 
1 'application Ab. A une premiere etape El, lors de 
1'appel par 1 1 application Aa de la methode methl sur 
1' objet Ob appartenant a 1 ' application Ab, c»est-a- 
20 dire lors de I'acces a l'objet Ob, une capacite sur 
un objet Oa appartenant a 1 1 application Aa est passee 
en parametre a 1 'autre application Ab. Pour mettre en 
oeuvre la protection specif iee par 1 1 application Aa 
dans sa vue a une deuxieme etape E2, le filtre Fa (Ob) 
25 ajoute le filtre Fa(Oa) et le passe en parametre de 
la methode methl a la place de la reference directe a 
1 'objet Oa. De meme, pour mettre en oeuvre la 
protection specif iee par 1 • application Ab dans sa 
vue, le filtre Fb(Ob) ajoute le filtre Fb(Oa) et le 
30 passe en parametre de la methode methl a la place du 
parametre regu. 

Les objets filtres Fa(Ob) et Fb(Ob), lorsqu'ils 
sont appeles, sont done charges d' installer des 
objets filtres Fa (Oa) et Fb(Oa) pour les references 
35 passees en parametre ; en. d'autres termes, deux 
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capacites illustrees par les filtres Fa(Oa) et Fb(Oa) 
protegeant I'acces a l'objet Oa sont ajoutees 
r„esp_ecjtivenient„dans_les -applications -Aa-et—Ab- 



5 II est indique ci-apres un exemple de classe 
filtre generee F_Iab_V pour la vue Iab_V donnee 
auparavant ,_ rappelee_ci^apres : — 

view Iab_V { 
10 void methl (I1_V1 pi) ; 

I2JV2 meth2 (); 
NOT void meth3 () ) 

} 

15 Pour les vues I1_V1 et I2_V2 sont creees 

respect ivement des classes filtres F_I1_V1 et 
F_I2_V2. II est suppose que les deux applications Aa 
et Ab qui cooperent se trouvent dans le meme 
environnement JAVA et les lignes suivantes sont 

20 encore ecrites en code JAVA, dans lesquelles le mot- 
cle public signif ie que la methode declaree suivante 
est accessible a toutes les classes, le mot-cle void 
signifie que la methode declaree suivante une fois 
executee ne retourne aucun resultat, et le mot-cle 

25 new designe un operateur de creation de classe : 

public class F_IabJV implements lab { 
lab obj; 

30 public F_Iab_V (lab o) { 

obj = o; 

} 

public void methl (I1_V1 pi) { 
35 obj. methl (new F_I1_V1 (pi)); 
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; 

publ-ie~I-2-V2~meth2~(-)—{- 

return (new F_I2_V2 (obj .meth2 ( ) ) ) ; 

s } 

puttlie~void~meth3--() — { — - — — — - 

// propager une exception 

} 

} 

La variable obj est une reference a I'entite 
suivante dans le chemin d'acces a l'objet, le 
deuxieme filtre ou l f objet reel. Elle est utilisee 
15 pour retransmettre l 1 appel s ! il est autorise. 

La methode F_Iab_V est la methode const ructeur 
de la classe filtre. Elle initialise la variable obj. 
Lorsque 1 'application Aa importe une capacite du 
serveur de noms et veut lui associer la vue Iab_V, 
20 elle appelle la methode constructeur en lui passant 
en parametre la reference JAVA regue. 

La methode methl retransmet un appel qui est 
done autorise, mais elle doit associer a la capacite 
passee en parametre pi la vue I1JV1. La methode methl 
25 cree par l'operateur new un filtre F_I1_V1 a partir 
du parametre re<?u, puis retransmet 1' appel en passant 
en parametre pi la reference au filtre cree. 

La methode meth2 retransmet l 1 appel et elle 
regoit en retour une capacite. Elle doit y' associer 
30 la vue I2_V2 . La methode meth2 cree done une instance 
de la classe F_I2_V2 a partir du parametre reqru et 
retourne par 1 1 instruction return la reference a 
I'objet filtre cree en retour de la methode meth2 . 
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La methode meth3 ne retransmet pas 1'appel 
puisqu'il n'est pas autorise, et propage done une 
exception- 

L r implantation lorsque les applications 
cooperantes Aa et Ab sont toutes les deux dans la 

— carte- a~ puce -re spec te les - principes- -decri-ts- ei— 

dessus. Par contre, lorsqu'une des deux applications 
se trouve hors de la carte, 1 ' implantation est 
io sensiblement differente. 

11 est rappele que les appels de methodes entre 
une station d'accueil SA, telle qu'un terminal, et 
une carte a puce CP comme montre schematiquement a la 
figure 6 sont implantes a partir de messages, appeles 
is unites de donnees de protocole applicatif APDU, entre 
la station d'accueil SA et la carte a puce CP, ces 
appels de methode n'etant effectues que suivant le 
sens de la station d'accueil vers la carte. En effet, 
la station d'accueil et la carte a puce, ou en 
20 variante deux cartes a puce ou deux controleurs dans 
une carte a puce ou un terminal, comprennent des 
microcontroleurs constituant des moyens de traitement 
de donnees qui sont respectivement maitre et esclave 
et qui dialoguent selon un protocole d'echange de 
25 donnees asynchrone qui oblige la station d'accueil a 
interroger periodiquement la carte pour que celle-ci 
declenche en reponse une action dans la station 
d'accueil. 

En variante, la station d'accueil dans la suite 
30 est remplacee par une autre carte a puce, e'est-a- 
dire les applications cooperantes Aa et Ab sont 
implantees respectivement dans deux cartes a puce, ou 
plus generalement dans deux controleurs. 

Le protocole d'echange de donnees asynchrones 
35 implique que, pour un appel relatif a un objet Obi 
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depuis 1 'application Aa dans la station d'accueil SA 
vers 1 'application Ab dans la carte CP a laquelle 
apparhient l'obje t Obi , lorsqu'il y a ret ran smissio n 
d'un appel entre deux objets filtres Fa (Obi) et 
Fb(Obl), relatifs a l'objet Obi, cette retransmission 
de 1' appel prenne la forme d'un echahge de message 
_entre la_station_ d_ , a_ccueil_ et la_ c_arte. _Une _ station__ 
d'accueil d'origine inconnue (pirate) est alors 
capable d'etablir un message correspondant a un appel 
de methode bien qu'elle ne soit pas reellement 
autorisee a realiser cet appel de methode. Ceci 
revient a creer une capacite ce qui n'est pas 
possible dans le schema de protection selon 
1» invention. 

Pour proteger les capacites contre ces attaques, 
des secrets, tels que mots de passe mdp, 
eventuellement bases sur des methodes de chiffrement, 
sont utilises. 

Comme montri a la figure 6, lorsqu'a une 
premiere etape E3 1 1 application Aa dans la station 
d'accueil SA appelle la methode meth2. sur un objet 
Obi appartenant a 1' autre application Ab dans la 
carte CP, c'est-a-dire lors de l'acces a l'objet Obi, 
et lorsqu'a une deuxieme 6tape E4 le resultat de cet 
appel de methode retourne une capacite d'acces sur un 
objet Ob2 appartenant a 1 1 application Ab, le filtre 
Fb(Obl) cree le filtre Fb(Ob2) dans le systeme 
d' exploitation de la carte CP pour cette capacite 
d'acces. Selon 1' invention, le filtre Fb(Obl) genere 
alors un secret, tel qu'un mot de passe mdp qui est 
stocke dans le filtre Fb(Ob2) et retourne au filtre 
Fa (Obi) qui le stocke egalement. Ainsi, lorsque le 
filtre Fa (Obi) cree le filtre Fa(Ob2) dans la station 
d'accueil SA pour la capacite d'acces retournee, le 
filtre Fa (Obi) passe au filtre Fa(Ob2) le mot de 
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passe mdp qui y est stocke. En d'autres termes, 
l'acces a 1' objet Ob2 est protege dans les 
applications Aa et Ab respectivement par deux 
capacites ajoutees illustrees par les filtres Fa(Ob2) 
5 et Fb(0b2) . 

Lorsqu'a l'etape E4 cette capacite retournee en 
"parametre "est - utilisl'e "pour appeler une methode sur 
l ! objet Ob2, l'appel entre les filtres Fa(Ob2) et 
Fb(Ob2) inclut le mot de passe dans le message APDU, 
10 ce qui permet au filtre Fb(Ob2) de verifier que la 
capacite d'acces a 1 ? objet 0b2 est valide. 

L' invention cree . ainsi par nommage une 
correspondance entre un objet et une capacite 
illustree par un filtre, geres par les systemes 
15 d» exploitation dans, les moyens de traitement de 
donnees, tels que station d'accueil et carte a puce. 
Si un objet est supprime dans une application, le 
systeme d 1 exploitation respectif detruit le filtre 
correspondant . 

20 

Ainsi, la cooperation entre une application Ab 
dans la carte avec une application quelconque 
necessite de gerer des capacites pouvant prendre deux 
formats, avec mot de passe si 1 1 application 

25 quelconque est exportee hors de la carte et sans mot 
de passe si elle reste dans la carte. 

Le schema de protection ci-dessus utilise des 
references, sortes de pointeurs, a des objet s JAVA 
qui sont presque des capacites. En effet, etant donne 

30 que le langage JAVA est sur, il n'est pas possible 
dans un programme JAVA d'etablir une reference a un 
objet et d* appeler une methode sur cet objet. Ceci 
implique que si un objet 01 cree un objet 02, l»objet 
02 n'est pas accessible a partir des autres objets de 

35 1 'environnement JAVA, tant que 1 'objet Ol ne transmet 
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pas explicitement a l'objet 02 une reference a ces 
autres objets. Cette transmission de reference ne 

P eu t ?e_ f^i^_ e _que_par_passage_de-_paramet re— l-orsqu-'-un— 

objet appelle l'objet 01 ou lorsque l'objet Ol 

5 appelle un autre objet. 
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RE VEND I CAT I ONS 

. 1 Procede de cont r 61 e d'.a cce s en t re deux 

applications (Aa, Ab) cooperant chacune au moyen de 
5 capacites sur des objets appartenant a 1' autre 
application, les applications cooperant a travers au 
moins un systeme d' exploitation et 6tant implante 
dans ~ un ~ nioyen de traitement de donnees (CP) , 
caracterise par l'etape suivante : 
io lorsqu'a 1'une (Aa) des applications, dite 

application demandeur d' acces, est donne un acces a 
un objet (Ob ; Obi) appartenant a 1' autre application 
(Ab) , dite application fournisseur d' acces ; 

creer (E0) deux capacites (Fa(Ob), Fb(Ob) ; 
15 Fa (Obi), Fb(Obl)) respectivement dans lesdites 
applications demandeur et fournisseur d' acces, en 
tant qu' objets ; 

la capacite creee dans 1 'application fournisseur 
d' acces (Ab) pour limiter 1' acces audit objet (Ob) 
20 et ; . 

la capacite creee dans 1 ' application demandeur 
d'.acces (Aa) pour associer 1 ' application demandeur 
d' acces a la capacite creee dans 1 ' application 
fournisseur d' acces (Ab) . 

25 

2 - Proced£ conforme a la revendication 1, 
comprenant lors de 1' acces (El; E3) a un objet (Ob ; 
Obi) appartenant a l'une (Ab) des applications, si un 
deuxieme objet (Oa ; Ob2) appartenant a l'une (Aa ; 

30 Ab) des applications est passe a cette application, 
l'etape d'ajouter (E2, E4) deux autres capacites 
(Fa(Oa), Fb(Oa) ; Fa(Ob2), Fb(Ob2)) respectivement 
dans les applications (Aa, Ab) pour proteger l'acces 
au deuxieme objet. 

35 

3 - Procede conforme a la revendication 2, selon 
lequel la capacite d' acces au deuxieme objet (Oa ; 
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Ob2) appartenant a l'une des applications est passee 
en parametre ou en resultat a 1' autre application. 

4 - Procede conforme a l'une quelconque des 
5 revendications 1 a 3, caracterise par 1 1 exportation 

d'une capacite depuis une application (Ab) vers 

1 '-autre- -application - (Aa)— en -l-'associantr -a- -un- nom— 

symbolique, et 1 1 importation de la capacite d'acces 
exportee dans 1 'autre application en interrogeant un 
io serveur de nom avec le nom symbolique. 

5 - Procede conforme a l'une quelconque des 
revendications 1 a 4, selon lequel les applications 
(Aa, Ab) sont implantees dans un moyen de traitement 

15 de donnees commun (CP) . 

6 - Procede conforme a l'une quelconque des 
revendications 1 a 4, selon lequel les applications 
(Aa, Ab) sont implantees respect ivement dans deux 

20 moyens de traitement de donnees distants (SA, CP) 
echangeant des messages d'acces a des objets 
distants . 

7 - Procede conforme a la revendication 6 
25 lorsqu'elle depend de la revendication 2 ou 3, selon 

lequel 1'etape d 1 a j outer deux autres capacites (E4) 
comprend le stockage d'un mot secret (mdp) dans les 
deux autres capacites (Pa(Ob2), Fb(Ob2)) passe a 
celles-ci par les deux capacites (Fa(Obl), Fb(Obl)) 
30 precedemment creees. 

8 - Procede conforme a la revendication 6 ou 7, 
selon lequel les moyens de traitement de donnees sont 
inclus respect ivement dans une carte a puce (CP) et 

35 une station d'accueil (SA) de la carte a puce. 



WO 01/42887 



26 



PCT/FR00/03463 



9 - Proc§de conforme a la revendication 6 ou 7, 

se Ton~legueI~ ies^moyens-de _ traitement— de-donnees-sont 

inclus respect ivement dans deux cartes a puce. 

5 

10 - Precede de generation d' applications 
caracterise en ce qu'il comprend : 

- une etape de developper une application (Ab) 
comprenant un objet (Ob) ou plusieurs objets (Ob, 

io Obi), sans restriction d'acces ; 

- une etape de definir des regies de droits 
d'acces a 1' objet (Ob) ou aux objets (Ob, Obi) 
compris au sein de 1 ' application depuis une seconde 
application (Aa) ou depuis plusieurs autres 

15 applications ; 

- une etape de transformer 1 ' application (Ab) 
comprenant le ou les objets (Ob, Obi) par ajout a 
ladite application (Ab) , de moyens de filtrage (Fa, 
Fb) des acces audit objet (Ob) ou auxdits objets (Ob, 

20 Obi) pour met t re en oeuvre le procede de controle 
d'acces selon les revendi cat ions 1 a 4 ; 

- une etape d'implanter 1' application 
transformee au sein d'un moyen de traitement de 
donnees (CP, SA) . 

25 

11 - Procede conforme a la revendication 10 selon 
lequel le moyen de traitement de donnees est inclus 
dans une carte a puce. 

30 12 - Procede conforme a la revendication 10 selon 

lequel le moyen de traitement de donnees est inclus 
dans une station d'accueil (SA) de la carte a puce. 
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